Commodore Free 38/Commodore_Free_Issue_38_2010_Commodore_Computer_Club.d64/iv michael

Text File | 2023-02-26 | 14KB | 485 lines

*************************************
   INTERVIEW WITH MICHAEL KIRCHER
 Creator of Minigrafik and Minipaint
      for the Commodore VIC-20
*************************************

Q. Please introduce yourself to our
readers

A. Hi, I'm Michael Kircher, 37 years
old, and working as electrical
engineer in Nuclear Fusion research.
I'm posting as 'Mike' in the VIC-20
Denial forum. When I don't use my
spare time for programming, I enjoy
swimming, cycling, photographing,
construction of models, and playing
a good game of chess.

Q. What is your first Memory of
computers and Commodore?

A. I became interested in computers
at quite an early age, when I could
try out my uncle's ZX81 in the
summer of 1982.

The most fascinating thing for me at
that time was, that a TV set
actually could display something
different than the normal TV
programme - something one could
think out oneself. I had been
tinkering around with electronic
kits already for some time then,
having built an AM transistor radio
at the age of nine. I really didn't
focus on Commodore until I got my
first computer.

Q. What was the first Commodore
Machine you owned, and did you
progress through the C64 and onto
the Amiga?

A. My first computer was a German
Commodore VC20, as a Christmas
present in '83. Even though it was
considered as family computer at
first, it was soon monopolised by
me. Intrigued by those strange DATA
statements full of numbers in BASIC
type-in programs, I even wrote my
first ML programs on the VIC until
its PSU gave up mid '86. I already
had a C=116 then, and later on, I
had a C=128, which then was my main
computing platform until early '91.
I changed to Acorn, and bought an
Archimedes A3000, which was followed
by an A5000. So at least I could
avoid the PC world for quite a long
time.

During that episode, I taught myself
ARM machine language, and C. This
led me to vastly different methods
of program design. Interestingly
enough for me, I found many of these
methods could be transferred back to
the machine language of the 6502; if
one was willing to throw some false
suppositions over board. All in all,
it was quite an interesting time
then: together with a friend, I
published some demos, and a disk
magazine called 'Hardliner', under
the handle/group name 'Architects'.

Even though, today there is nothing
much more than the PC monopoly. One
good thing about it, is that
nowadays emulators, and
cross-developing allow programs to
be written for our first machines,
that we simply couldn't do in former
times without those tools at hand.

Over the time, one main interest for
me always had been computer
graphics. So, when emulators had
matured enough, I thought what I
could have achieved with the VIC,
had its PSU not given up early?

Q. Can you tell our readers about
the VIC-20 graphics extension
MINIGRAFIK?

A. MINIGRAFIK is a compact tool for
the VIC-20, that provides a high
resolution graphics screen of
160x192 pixels with at least a +8K
RAM extension being present. It
features commands for changing
between text, and graphic modes,
pixel plots, line drawing, and it
can save, and load the graphics
screen. There is support to mix
hires, and multi-colour graphics on
the same screen, the latter which
allows up to four colours being
placed nearby on the screen, at the
cost of resolution.

Q. So when and where did the idea
for MINIGRAFIK come from?

A. A friend of mine gave me a tape
with the original version of
MINIGRAFIK in 1985. It had been
published by a German computer
magazine as type-in program. The
original version had been written
for an unexpanded, or +3K expanded
VIC-20, and featured a 128x128 pixel
screen. Line drawing, and graphics
load/save commands were not
included, but even so I wrote some
programs for it, like function
plotters, pie charts, and a simple
joystick-driven graphics editor. The
tape, and the extension later got
lost in time.

I had subscribed to the Denial forum
late 2004, and in 2006 there
appeared a discussion thread about
hires graphics in general, which
gave me the incentive to reconstruct
MINIGRAFIK, this time with a
resolution of 160x192. Only the
internal memory of the VIC-20 is
accessible by the VIC chip, and I
chose this resolution as it is the
maximum one, which can be displayed
without clobbering the lower 1K used
by CBM BASIC, and KERNAL.

Besides the increased resolution,
the added line draw, and load/save
commands, I also included enhanced
support for multi-colour graphics.

Q. Is the extension still evolving,
for example are there still new
features to implement?

A. As it stands, the current version
of MINIGRAFIK already gives a good
starting point for graphics oriented
programs. Many graphics primitives
can be coded with pixel plots, and
line drawing alone. For example, I
didn't include a BOX command, as
that can simply be expressed as
sub-routine with 4 line commands.

Some sensible candidates might be a
colour selection command,
circle/ellipse draw, flood fill, and
text output. Even though, the
usefulness of a dedicated colour
selection command can be disputed,
because it would only replace up to
3 POKEs for eye candy, but no other
advantage. The other features will
most probably be implemented as
SYS-callable library routines in
machine language, leaving the kernel
of MINIGRAFIK untouched. Currently,
a program using MINIGRAFIK can count
on using nearly its whole code, so
there is no baggage of unused parts
of MINIGRAFIK around when it is
loaded.

Q. Apart from the obvious VIC-20
limitations like memory and screen
resolution, what main problems did
you face implementing MINIGRAFIK?

A. The main concern was, that
MINIGRAFIK does not operate on its
own, but acts as support library for
user programs. That required a
seamless integration into the BASIC
interpreter. I also wanted the
extension to work on both PAL, and
NTSC TV systems. For this, the two
versions of the VIC chip must be
programmed in a different ways, an
auto-detect routine takes care of
that.

Q. Can you explain to our readers
how to use the MINIGRAFIK extension
from their own programs, for example
can you use BASIC commands to use
the features of MINIGRAFIK?

A. MINIGRAFIK installs itself as
extension to CBM BASIC. The new
commands, and functions are all
prefaced by an '@' character. @ON,
@CLR, @RETURN select graphics mode,
clear the graphics screen, and
return to text mode. @LOAD, and
@SAVE access tape or disc to load,
or save the graphics screen. '@' on
its own specifies a pixel plot, or
line drawing command, with a syntax
similar to the DRAW command in BASIC
3.5 or 7.0. Finally, the @()
function takes a co-ordinate pair as
two parameters, and returns the
pixel colour within a numeric
expression.

I could have added additional
tokenizing, and de-tokenizing
routines to give the commands their
own names. Still, the combination of
a flagging character, and standard
BASIC 2.0 tokens with fitting
descriptions of the intended use
seemed satisfactory to me.

The screen bitmap has a simple
address function, so programs
written in machine language have
fast access.

Q. I presume the whole of MINIGRAFIK
is implemented as machine code? How
big is the code when loaded into
memory?

A. Indeed MINIGRAFIK is 100% machine
code, only 1K in size. Even though,
the memory from addresses 4096 to
8191 is permanently allocated for
graphics display while the extension
is active. With the minimum required
+8K RAM extension that means there
is still 7K available for BASIC
programs.

Q. Has MINIGRAFIK been used in any
recent VIC-20 games?

A. It found use in 'VIC=toria Gold
Edition', a strategic board game set
in Ancient Rome, which Alessandro
Ubiali, and I co-developed in late
2008. Some graphics for 'Realms of
Quest III' by Ghislain de Blois were
prepared off-line with
MINIGRAFIK-enhanced conversion
programs. A few weeks ago, the text
adventure 'Island of Secrets' had
been re-released with a new LOOK
command to show screens of more than
30 locations in the game. And, while
it might not strictly qualify as
game in the usual sense, I've also
written a LIFE simulator which uses
MINIGRAFIK.

Q. When or where did the program
MINIPAINT evolve from?

A. Really, MINIPAINT started out
from the editor part of the LIFE
simulator I just mentioned. To get
the features of a full-fledged
graphics editor, and for speed
reasons, I had to translate many
parts to machine language, but there
is still a main part written in
BASIC which interfaces that ML
library to MINIGRAFIK.

I did the first drafts of MINIPAINT
in 2008, the project then lay
dormant for nearly one year until I
picked it up again last year.

Q. What was the main idea of
MINIPAINT?

A. MINIPAINT, at its heart, is a
pixel-oriented graphics editor.
Before I had written MINIPAINT, the
two main methods of creating
graphics were either using
MINIGRAFIK itself to do "programmed"
graphics, or import images from PCs
or other sources, converting them
into the format specified by the
@LOAD, and @SAVE commands. One of
these programs, PGM IMPORT, does a
fairly good job of translating a
80x192 pixel 256 grey-scale level
PGM file into a MINIGRAFIK
multi-colour screen dithered to 13
intensity levels.

Still, the VIC chip is capable of
displaying really stunning pictures
when a good graphician has complete
control over the finest aspects of
the displayed picture. This is, what
MINIPAINT is designed for. Of course
it can also be used to fix up
conversions.

Q. I see you have an example piece
of art work "Tutankhamun", can you
take our readers through the process
to draw this on the VIC with
MINIPAINT?

A. I used a cropped photo of the
mask of King Tut, and a variant of
PGM IMPORT to produce a first
workstage in the colours blue,
orange, light orange, and white.
Since I had selected white as
foreground colour, I could add
shades in black as another
foreground colour within MINIPAINT.
Another small part, the snake at the
top, was repainted in cyan colour as
well.

It was mainly a matter of luck I had
no problems with attribute clashes
of the foreground colour with this
picture, and so it turned out quite
well.

Q. How long did the picture take to
complete?

A. The preparation on the PC, and
the conversion maybe took 15
minutes. Adding the black shades
incurred the longest part of
completing the picture, roughly 2
1/2 hours.

Q. Can MINIPAINT drawings be used in
user programs or called as
standalone PRG files for demos, etc.?

A. Since MINIPAINT, and MINIGRAFIK
share the same picture format - the
save/load function in MINIPAINT is
implemented with MINIGRAFIK commands
- the pictures can simply be loaded,
and displayed by your own programs
with the @LOAD command. The picture
files themselves are actually
executable PRG files. That means,
even if one does not currently have
MINIGRAFIK, or MINIPAINT available,
that picture can be displayed by
LOADing it ',8' (*not* ',8,1'!), and
then typing RUN.

Q. Are both applications well
documented with user guides and
examples?

A. MINIGRAFIK is still being
discussed in the thread in Denial
about hires graphics. I had posted
quite some example programs there
over time, many of which are now
also hosted on my SkyDrive account.

MINIPAINT features a small, but
handy on-line help system, which is
invoked by pressing the '?' key.

For both programs I am currently
preparing a comprehensive manual,
which includes a tutorial for
MINIPAINT, example programs, and
utilities using MINIGRAFIK, and
additional documentation for those
who want to access the hires screen
from machine language.

Q. Have you had much feedback from
users of the applications?

A. There has been quite some
feedback, mostly by Denial fellows.
While I did the design, and coding
of MINIGRAFIK all by myself, for
MINIPAINT I got some very important
feedback during development from
Shane Fell, and Vanja Utne.

MINIPAINT wouldn't be the program it
is now without their suggestions.

Q. Have you had any thoughts about
other applications that will utilise
the MINIGRAFIK add-on for the VIC?

A. The hires screen can be used to
"host" output from a 40 column
emulator. Even though there are some
of these programs around, like
FAT-40, they all suffer from a
sluggish output. This is mainly
because they replicate the whole
BASIC editor functionality within
themselves - there's not much room
to optimize things, when the API
focuses on single character output.

Text output on a bitmapped screen is
heavily sped up when a routine that
can print complete lines at a time.
Such a routine already has been used
for the dialogue boxes in MINIPAINT.
These ideas might end up in a 40
column text editor. Together with an
assembler, it might even be possible
to produce a new kind of programming
environment for the VIC-20.

Q. What 3 things would you change
about the VIC-20 if you were able to
go back in time and help redesign
the machine?

- The 3K RAM between 1024 to 4095
  should have been populated as well.
  That would have allowed to locate
  the screen at 1024, not only
  increasing the amount of accessible
  RAM for the VIC chip, but there
  would also never have been any
  problems because of a relocating
  text screen with bigger RAM
  extensions.

- Nice would have been an error-free
  shift register in the VIA chip.
  That would have given us fast
  floppies right from the start,
  without the necessity for the CBM
  developers to re-implement the IEC
  protocol bit-banging style in
  software.

- Separate luma, and chroma, instead
  of composite video output.

These features would have kept the
essence of the VIC-20. And for any
other enhancements regarding
graphics, sound, and memory, there's
still the C=64 around. ;)

==================================